1. Technical Field
This disclosure relates generally to cryptographic key lifecycle management.
2. Background of the Related Art
Business data is growing at exponential rates, and along with that growth is a demand for securing that data. Enterprises have responded by implementing encryption at various layers, such as in hardware, on the network, and in various applications. This response has resulted in a series of encryption silos, some of which hold confidential customer data, with fragmented approaches to security, keys and coverage. Further, different applications across the enterprise often employ different encryption methods. Thus, for example, some departments in the organization may use public-key cryptography while others use secret-key or hashes. Still others do not encrypt data while it is at rest (such as when it is stored on a device or in a database) but only when the data is in motion, using virtual private networks (VPNs) to secure the data pipeline. Key management for these encryption approaches is often similarly fragmented. Sometimes key management is carried out by department teams using manual processes or embedded encryption tools. Other times, the key management function is centrally managed and executed. In some cases, no formal key management process is in place. This fragmented approach to key management can leave the door open for loss or breach of sensitive data.
Key Management Interoperability Protocol (KMIP) is a new standard for key management sponsored by the Organization for the Advancement of Structured Information Standards (OASIS). It is designed as a comprehensive protocol for communication between enterprise key management servers and cryptographic clients (e.g., from a simple automated device to a sophisticated data storage system). By consolidating key management in a single key management system that is KMIP-compliant, an enterprise can reduce its operational and infrastructure costs while ensuring appropriate operational controls and governance of security policy.
There is a challenge, however, in implementing KMIP with existing key management server architecture that is based on a centralized model, namely, one wherein clients are largely pre-provisioned with all of the cryptographic materials that they might need. This centralized model of this type accommodates a device-oriented support paradigm wherein the devices are sophisticated (e.g., storage devices) and have administrators responsible for their administration and management. KMIP, on the other hand, treats cryptographic clients uniformly and, more importantly, as entities that are intelligent and themselves capable of specifying cryptographic information, such as correct key sizes, encryption algorithms, and the like. The KMIP view of cryptographic clients is inconsistent with typical storage device types that today interact with enterprise key management servers. Indeed, such storage devices typically are better served with pre-provisioning support. As a consequence, there is an incompatibility between, on the one hand, the ability of existing key management servers to set up cryptographic attributes ahead of time, and, on the other hand, KMIP's theoretical support of otherwise highly-capable cryptographic clients that need no such pre-provisioning.
Although KMIP was designed to allow multiple-client authentication and authorization schemes, the only mechanisms defined in the first version of the protocol are UID (user identifier) and password, and client-side certificates. A key management server, however, needs to know more about the identity of its clients to be able to group them into device types and device groups and thus match them with pre-provisioned materials that befit their needs.
The subject matter of this disclosure addresses this need.